Split Codecompanion Tools for fine-grained control and drop slash command#192
Split Codecompanion Tools for fine-grained control and drop slash command#192
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #192 +/- ##
=======================================
Coverage 99.48% 99.48%
=======================================
Files 21 21
Lines 1552 1552
=======================================
Hits 1544 1544
Misses 8 8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
232f390 to
1f9c0ed
Compare
c9c5918 to
669833b
Compare
359c7a1 to
f584643
Compare
|
@olimorris just so we're on the same page, it's now recommended to remove individual |
Yep. Ideally the tools should be granular and simple enough that a description will suffice. Of course you have a description field within the parameters as well. Some examples from GitHub Copilot: "name": "grep_search",
"description": "Do a text search in the workspace. Use this tool when you know the exact string you're searching for.",
"name": "read_file",
"description": "Read the contents of a file.\n\nYou must specify the line range you're interested in. If the file contents returned are insufficient for your task, you may call this tool again to retrieve more content.",
"name": "list_dir",
"description": "List the contents of a directory. Result will have the name of the child. If the name ends in /, it's a folder, otherwise a file", |


This PR splits the codecompanion tool into separate
ls,queryandvectorisetools. This'll provide better control and simplify the codebase for future iterations.The slash command
/vectorcodeis also being dropped. This is because the tools are more powerful and easier to maintain compared to the slash command. Also, the way it works (using information from the code buffer as query keywords) is suboptimal anyway, at least for an agentic workflow in codecompanion.EDIT: new extension config: